SOLR-13568: Expand component no longer caches per-page group queries in the filter cache - #5014

🤖 AI text below 🤖 (posted on behalf of Nick Shanin)

https://issues.apache.org/jira/browse/SOLR-13568

What happens today

Paging through expanded groups stores a one-off group query in the filter cache on every page.

When paging through expanded groups, ExpandComponent adds the group query for the current page to the request's filter list. That per-page query is specific to the page being returned, but it is stored in the filter cache anyway, so paging through expanded results fills the filter cache with entries that are rarely reused.

What this change does

The per-page group query is wrapped with caching disabled, so it still filters the page but is never stored in the filter cache.

The per-page group query is wrapped in a WrappedQuery with caching disabled before it is added to the filter list. It still filters the page exactly as before; it is simply no longer stored in the filter cache. No other query's caching behavior changes.

Proof

The new test fails on base code, where the filter cache holds 5 entries instead of 3, and the suite passes 9 of 9 at this head.

Verified at head ac5d60c on 2026-10-06 (tidy clean, Error Prone compile clean, :solr:core:check -x test green).

• TestExpandComponent.testPerPageGroupQueriesNotCached pages through expanded groups and asserts the per-page group queries do not land in the filter cache. It fails on the base code, where those queries are cached (re-run at ac5d60c: 9 tests, the new test the only failure, filter cache size expected:<3> but was:<5>), and the suite passes here: TestExpandComponent 9/9.

A choice to check

The choice is between always keeping the per-page group query out of the filter cache and a per-request switch that restores caching on request.

This change always keeps the per-page group query out of the filter cache. The alternative is a per-request switch that restores the current caching behavior for requests that ask for it. Always-off is the simpler rule and the cached entries are rarely hit, but if maintainers would rather keep cache hits available for repeated identical page requests, the switch is the route to take. Was always-off the right call?

Limits

Only the expand component's per-page group query is affected, and a repeated page now recomputes its group filter every time.

Only the expand component's per-page group query is excluded from the filter cache. Any other caller that adds single-use queries to a request's filter list keeps the current caching behavior; that broader pattern is out of scope here. The trade: the same page of the same query, requested again by any user, builds the same group query, and before this change that second request could find the filter in the cache; it now recomputes the group filter every time. For a popular first page that recompute is a recurring cost that has not been measured, paid in exchange for the filter cache no longer churning while paging.

Changelog: changelog/unreleased/SOLR-13568.yml (type fixed)

AI assistance

AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution.